The present invention relates to computer systems, and particularly to single-user or few-user small systems.
How Application Programs Interact with Hardware
One of the most basic needs in computer architecture is making it easier for a variety of software programs to interact correctly and efficiently with a variety of hardware configurations. Much of the development in computer architecture can be seen as a steady progression of techniques for addressing this need.
Note the emphasis on efficiency, in the foregoing statement. Even where existing standards can assure compatibility, the search for greater speed or expanded functionality will frequently draw programmers to circumvent the software standards. A good example of this countercurrent appeared in the early days of graphics development on the IBM PC: the BIOS provided a standard interface to video driver operations, but software developers discovered that they could vastly improve performance by making calls directly to the video driver hardware. Thus adherence to the standard architecture was not enough to assure computer designers that their customers would be able to run popular IBM-compatible software, such as Flight Simulator, on their supposedly IBM-compatible machines. Thus, there is a continuing tension between compatibility and efficiency.
When any particular piece of hardware is examined in isolation it can usually be best described in terms of electrical relationships. For example, a memory specification may state that, within a certain range of delay after certain voltages appear on certain lines, certain other lines will be driven to a corresponding state (which is dependent on the data previously stored in the memory). The specification for an input device, such as a keyboard, may state that, when certain voltages appear on certain lines, a particular input operation may be considered to have occurred. The specification for an output device, such as a video card, may state that, when certain voltages appear on certain lines within a certain timing relationship and protocol, each pixel within a certain defined display device will be driven to an optical state which corresponds to a certain portion of the protocol. However, a commercial application program will be written in a programming language (e.g. in assembly language or in C) which is somewhat machine-independent. There is a great difference between these two levels of description: but this gap must be bridged in order to economically develop application software which can run on a wide range of machines.
Several layers of software and firmware structure are used to mediate between application programs and the underlying hardware. To better show the context of the invention, these layers will be described below in greater detail.
Hardware Variability
Computer hardware configurations are inherently diverse. The complexity of any modern computer system is high enough that even a very detailed standard architecture (such as the "AT" architecture which was introduced with IBM's 80286-based machines) will not prevent variations from occurring. Whenever designers independently work within a standard they are likely to find ways to make improvements. As such variations occur, some of them will be seen to be significant. Thus the future will often find that any standard contained significant "gray" areas.
This is true not only in motherboard design, but also in I/O devices. For example, two display drivers which both conform to the VGA standard may nevertheless differ in timing, to an extent which may be significant to some software applications. Moreover, there will always be users with needs for specialized input or output devices.
Even within the very restricted world of "PC" architectures (where all machines must conform to numerous constraints of the "standard" architectures), hardware variability continues to be a problem. The range of hardware variability in (for example) computers which can run UNIX is far larger.
This hardware variability is not merely accidental, but will continue: users are eager to take advantage of new developments, and the pace of innovation is generally far too rapid to permit stabilization of standardized hardware configurations.
Layers of Software and Firmware Structure
In order to mediate between application programs and the underlying hardware, several layers of software and firmware structure are used. To better show the context of the invention, these layers will be described below in greater detail.
Startup Software (POST, Bootstrap, etc.)
When power is first applied to a computer, the various hardware elements (chips and subsystems) will each have their own internal procedures (reset procedures) to regain a stable and known state. However, at some point (if the hardware is intact), these reset procedures will have ended, and at this point the CPU performs various important overhead tasks. These include, for example, surveying the system configuration, performing sanity checks on system hardware, issuing diagnostic signals (such as sounding beeps through a speaker or turning on LEDs), and permitting the user to branch into an NVRAM configuration program under software control. This phase of operation is generally referred to as "POST" (Power-On-Self-Test). After POST, a "bootstrap" program is run, to permit the CPU to begin execution of other software. For robustness, the POST and bootstrap software is normally stored in a read-only memory. The bootstrap program launches the CPU on execution of the primary operating system software; depending on how the system has been set up, the boot software may direct program execution into DOS, Unix, PS/2, a DOS variant, or another operating system. This is normally automatic and predetermined, but is manually user-selectable in some systems. However, the choice of operating system is not particularly relevant to the inventions described in the present application the primary operating system can then be used by the user to launch an application program, either manually or automatically.
Basic Input/Output System Software (BIOS)
In many types of modern personal computers (and in all "IBM-compatible" personal computers), a key part of the system software is a "basic input/output system" (BIOS) program. See generally, e.g., the P. Norton, THE PETER NORTON PROGRAMMER'S GUIDE TO THE IBM PC (1985), which is hereby incorporated by reference. The BIOS program contains frequently-used routines for interfacing to key peripherals, The term "peripheral" or "peripheral component" normally refers to those components of a computer system which are not on the motherboard, i.e. which must be addressed through a system bus or over a defined port However, the usage of this term is somewhat variable; sometimes it is used to refer to any I/O device, or only to refer to components which are optional add-ons for interrupt handling, and so forth. Thus, the BIOS software provides some degree of machine-independence. However, in PC-class computers, this independence is not fully exploited by the available commercial software. Many programs bypass the BIOS software, and directly access the underlying hardware addresses or devices. See generally Glass, "The IBM PC BIOS," BYTE. April 1989, pp. 303ff.
For system robustness the BIOS software is normally packaged in a read-only-memory. However, in 1991 IBM introduced a PS/2 system in which the BIOS is at least partially stored on disk. In fact, it is normally packaged together with the startup software mentioned above. Packaging the BIOS, POST and boot routines in ROM makes a very robust firmware system. Short of hardware damage, it is very difficult for a user to distort the system to the point where it will not start up and run (if the operating system software is present). However, this system also provides a considerable degree of flexibility. As the operating system up (after the POST and boot routines), the user can remap address pointers to revector BIOS calls away from the standard BIOS routines, if desired. (It is also common for users to map out the entire BIOS contents into fast RAM, for greater speed). Thus, nowadays the term "BIOS" is often used somewhat more broadly, to refer to this whole collection of basic system routines. However, in the present application references to "BIOS" will normally refer to the BIOS in its narrower sense, i.e. to the collection of I/O handling routines (and associated routines) which can be called on by the operating system or by the application software.
Customized BIOS and BIOS Extensions
The BIOS in IBM-compatible computers is accessed by interrupts, but the vectors for those interrupts can be diverted to other addresses (by overwriting an address pointer in system RAM). This capability, significantly expands the flexibility of the BIOS, and programmers use it very, frequently.
However, while the capability to divert BIOS vectors is useful, it is not sufficient to address many needs. Changes to the interrupt-handling vectors will not affect other portions of the BIOS. Computer designers have found it highly desirable to prepare (or obtain) customized BIOS routines to fully exploit the advantage of their systems. For example, such customized BIOS routines are commonly necessary in very-low-power portable systems, to implement power saving features which maximize battery lifetime. BIOS customization has increasingly been recognized as an important element in rapidly developing a reliable advanced system. See generally Scheier, "Phoenix counters competitors with diversified BIOS offerings," PC Week, vol. 4 no. 38 (Sept. 22, 1987) at 135f; Guterman, "CompuAdd adopts new ROM BIOS for clones," PC Week vol. 5 no. 28 (Jul. 11, 1988) at 6; both of which are hereby incorporated by reference.
One function often provided by BIOS customization is "hot-key" access to a setup menu, or to low-level system hardware features (e.g. monitor brightness adjustment). Such capability is very, useful to system designers, but normally it has had to be realized in a machine-dependent way (so that large chunks of BIOS have had to be rewritten every time a change was made).
Another problem with prior hot-key add-ons is that, if the BIOS interrupt vector for key-handling was diverted, the hot-key capability could be lost. Since many applications do divert the keyboard interrupt (INT9), no critical functionality could be made dependent on such a hot-key operation.
Operating: System Software
The application software will normally interface to an operating system (such as DOS, DOS+Windows, PS/2, UNIX of various flavors, or UNIX plus X-windows). The operating system is a background software program. Some operating systems run continuously, or at least start up at regular intervals, even while an application program is running; other operating systems merely provide capabilities which can be called on by the application software which provides an application programming interface (API) for use by the application software. Thus, the programmers writing application software can write their software to fit the API, rather than having to find out and fit the peculiarities of each particular machine. (A common way of stating this is that the API allows programmers to write for the "virtual machine" defined by the API.) See e.g., Quedens, "Windows virtual machine," PC Tech Journal vol. 5, no. 10 p. 90, 92-3, 95, 97, 99-100, 102 (October 1987), which is hereby incorporated by reference.
Graphical User Interface (GUI) Operating System Add-Ons
Some operating systems have been enhanced by the addition of overlaid supplemental operating systems. For example, Windows is a supplement to DOS, and X is a supplement for UNIX. The use of such hybrids does not greatly affect tile foregoing considerations, except that it makes the compatibility issues even more difficult: the designer of a DOS machine must expect that customers will be running some DOS programs, and some Windows programs, on the same machine.
Device Driver Software
A device driver is a lower level of operating system software. Typically a device driver interfaces to the actual peripheral hardware components, and provides routines which application software can use to access the hardware components. Thus, the application software can simply make a call to an installed software subroutine, instead of having to find the specifications of each peripheral device and branch accordingly, whenever a peripheral I/O operation is needed. This permits application software to ignore the detailed specifications of peripheral hardware.
Normally device driver software must contain a description of each target hardware platform. Thus, the software must be revised repeatedly, for reasons which are beyond the control of the companies making peripherals.
In personal computers, installable device drivers were first introduced in DOS 2.0. The role of device drivers has since been expanded, in subsequently introduced operating systems.
In particular, OS/2 provided expanded support for device drivers, including a library of "DevHlp" routines which can be called by device drivers. See generally Duncan, "An examination of the Dev Hlp API (writing OS-2 bimodal device drivers)," 3 Microsoft Systems Journal no. 2 (March 1988) at 39ff; Schmitt. "Designing drivers for OS/2: I," PC Tech Journal vol. 5, no. 12, p. 164 (1987); and Schmitt, "Designing drivers for OS/2: II," PC Tech Journal vol. 6, no. 2 p. 136-155 (February 1988), all of which are hereby incorporated by reference.
System Configuration Tables
Some computer systems have previously used a feature table, stored in nonvolatile memory, to describe various characteristics of the machine. The IBM AT BIOS uses such a feature table (stored in battery-backed CMOS memory). This feature table, in expanded form, has also been used in the IBM PS/2 systems and has been utilized in the system BIOS of all IBM AT- and PS/1-compatible personal computers. This table is in the form of a bit map where each bit refers to specific hardware implementations employed by the designers of the machine. A pointer to this table may be obtained through executing a software interrupt. More specifically, executing interrupt 15h with AH=C0h will return a pointer to the table in ES:BX. However, this feature table is restricted to merely listing certain hardware features in the machine, such as the number of DMA controllers, and does not provide an interface to these features. Furthermore, the elements of the list are fixed.
In the Phoenix Technologies BIOS, there are specified entry points at hard-coded addresses which will perform certain machine-specific functions. These are few in number, must be at fixed addresses, do not support protected mode applications and it is not possible to easily see which features are supported by which machines except by restricting to the common subset.
Under the EISA standard, an EISA Configuration memory is used to store a limited feature table of EISA peripherals on the EISA bus. See generally Glass, "Inside EISA," BYTE magazine, November 1989, at 417ff, which is hereby incorporated by reference.
Application Software
From a system designer's point of view, the application software is (subject only to the minimal constraints of the architectural standards) wholly unpredictable. Many clever people are constantly looking for new ways to exploit the standard architecture, and many innovations continually result. Thus, hardware architects must expect that the application software will not only be unpredictable, but will be as unpredictable as possible. Common applications include spreadsheets, word processors and publishing programs, databases, games, project managers and a wide variety of others: but inevitably users will also run customized applications, and new types of applications.
Utility Programs and Hardware
In recent years, many personal computer manufacturers have expanded their product lines. This has dramatically increased the difficulty of supporting an entire product line in terms of the standard software products that a manufacturer may choose to include or sell with its computers.
Examples are diagnostic programs, operating system software and utility software. It is increasingly necessary to provide a means for such software to identify the individual machines and their unique features, without having to be rewritten each time a new product is introduced.
Furthermore, it may be difficult or undesirable to implement even similar features in exactly the same way, since each design has different constraints in terms of cost and each will incorporate the knowledge gained by building the previous product. The problem gets worse as a product line ages. It is desirable to continue to support older products with newer versions of software, and it is also desirable for older versions of software to run unmodified on newer platforms. One solution to this problem is to write the software to the common subset of functions supported by all platforms. However, this does not allow the manufacturer to differentiate his product from the competition. Consequently, it is desirable for each individual machine to have the capability to identify its own unique feature set to such software, while at the same time providing the individualized means for carrying out those functions.
Innovative Computer System with Self-Describing Extensions to BIOS
The present invention provides a personal computer architecture with an additional layer of overhead software (or firmware) structure. This additional layer of software structure is used to provide access to additional low-level hardware-specific features in a manner which is independent of the operating system. In the present application, these additional low-level hardware-specific features are referred to as "extended features."
Extended Features
An "extended feature", in the presently preferred embodiment, is normally a system level routine used to service hardware components or to obtain system information unique to Dell hardware systems. The detailed disclosure below lists some of the numerous extended features which have been implemented to date. However, of course, other functions can be provided as well.
The disclosed self-describing system software extension provides a lower level of software-hardware interface "cushioning," which device drivers can call on. Thus, the self-describing system software extension can also be exploited to permit device drivers to be more hardware-independent.
The self-describing system software extension is particularly advantageous in its application to an evolving product line within the same overall standard.
Self-Describing Feature Table
The disclosed innovations provide methods by which a computer with some quantity of non-volatile storage can present a self-describing interface which also provides a means for carrying out machine-specific functions in a non-specific way.
In the presently preferred embodiment, the feature table and the machine-specific routines are programmed into EPROM devices, at the start of the "OEM reserved" block of addresses in the BIOS memory, space. In IBM-compatible computers, the BIOS commonly occupies the 64 K or 128 K of address space just below the top of the lowest megabyte of the total memory address space.
An important element of the method is a table which contains a signature to identify it with the system software architecture described herein, and a series of entries with the following information:
Feature ID--a unique identifier for each specific machine-specific function. PA1 Attributes--describe the operating environment for proper access to the function. May limit access to real or protected mode or possibly even to specific operating environments. PA1 Service Routine--a pointer to the program code that performs the requested function. PA1 Data Block--Features may also include an optional data block.
The self-describing system software extension of the presently preferred embodiment includes a self-describing feature table, which can track the peculiarities of the actual hardware configuration of each system as configured. The self-describing system software extension, with this feature table, provides low-level translation for hardware peculiarities.
By use of this feature table, the disclosed innovations provide a computer system which can be updated with self-defining extensions to the basic BIOS (which remains in read-only memory). The basic BIOS must be modified to make use of these self-defining extensions; but, once such a modified BIOS has been installed, it does not have to be updated frequently. Instead, the routines in the modified BIOS can make use of the self-defining feature table without further changes to other portions of BIOS. Thus, for example, in one class of alternative embodiments, the feature table is located in NVSRAM, and a ROM holds the basic BIOS and a pointer to the feature table.
Application Programming Interface to Self-Describing Feature Table
One contemplated and advantageous class of embodiments uses a standard API to the feature table to provide increased portability of access to XBIOS features across applications. (Thus, for example, an OS/2 device driver can be written to wrap this API around XFT calls in such a way that any OS/2 software can make XFT calls through this API.) This provides optimal access to the machine-specific routines across the whole family of computers.) In the sample embodiment described in detail below, this function is not yet included. However, as will be apparent to those skilled in the art, this can readily be implemented in various ways, within the architecture described below, if desired.
Device Drivers in the Innovative System
The disclosed architecture provides access to machine-specific features, with enough information to permit device drivers to be written in a machine-independent way (within the Dell family of computers). Some specific examples of such drivers are given herein, but of course other drivers can also make use of the extended BIOS features as well.
Keyboard Driver
One very advantageous piece which is included in the presently preferred embodiment is the keyboard driver, which permits the user to access XBIOS functions, without exiting his application, by hitting "hot key" combinations. This is highly advantageous in portable systems, since the user can fine-tune his system's hardware parameters to match changing conditions. Thus, the disclosed system allows the user to send BIOS-level function calls right through an application, without saving the context of the application.
This keyboard driver runs under DOS, so it is still possible for a user to disrupt this driver by remapping the keyboard interrupt INT9): but at least this driver does permit language customization to be combined with hot-key access to extended-BIOS functions.
OS/2 Initialization Driver
Another advantageous part of the presently preferred embodiment is an OS/2 initialization driver, which permits easy initialization of hardware-specific functions for OS/2 initialization. This driver, in its presently preferred embodiment, is listed in the appendix.
Common Device Drivers across a Family of Computers
The disclosed innovations have been implemented on a number of different computer systems within the Dell system product line. As of the effective filing date of the present application, these include both EISA and ISA systems; systems based on 80486, 80386, and 386SX microprocessors; systems running at 33 MHz, 25 MHz, and 20 MHz clock rates; systems with one or two hard disks, or up to 10 disks in a drive array; systems with monochrome, VGA, or high-resolution graphics adapters; and a wide variety of other configuration options. Moreover, the disclosed innovations are currently being made available in all new Dell computer designs. Thus, it is expected that, in the near future, every computer in the Dell product family will include the XBIOS described below (or an update thereof).
As discussed below, the disclosed innovations are believed to be advantageous not only as applied to a single computer, but also as applied to a whole family of computers. In the case of the preferred embodiment, suppliers of computer peripherals can be increasingly confident that a device driver which takes advantage of the self-describing system software extension of the presently preferred embodiment will apply to every current Dell computer, and also to future models which the supplier has not yet seen or heard of.
Backward Software Compatibility
A substantial advantage of the disclosed architecture is that additional BIOS-level functions can be readily added into computer system designs, as soon as the innovations occur, without any necessity for radical BIOS changes. The self-describing system software extension of the presently preferred embodiment itself does not degrade BIOS compatibility with prior ISA or EISA machines; and once the self-describing system software extension of the presently preferred embodiment is installed, further extensions to BIOS functionality can readily be achieved.
Additional Background
Two previous proposals for achieving machine-independence will now be discussed, with reference to the present inventions, in order to provide a clearer discussion of how the teachings of the present application differ from these prior teachings.
The "Advanced BIOS" (ABIOS) in PS/2 Architectures
The PS/2 architecture, which IBM introduced in 1987, included a so-called "advanced BIOS" or "ABIOS" There are actually two versions of ABIOS available, since IBM has offered a simplified ABIOS for use on machines other than IBM PS/2s. However, the full functionality of ABIOS is available only on an IBM PS/2. The features of this version of ABIOS are most germane to the background of the present invention (in additional to a more conventional BIOS, known as the "compatibility BIOS" or "CBIOS"). The user can elect to use the CBIOS instead of the ABIOS if he wishes, for downward compatibility; the CBIOS and ABIOS are not designed to run simultaneously.
The ABIOS is a more high-level software structure than ordinary BIOS, and has many features added to enhance performance in OS/2 (which, unlike DOS, is a multi-threaded operating system). However, ABIOS is so complex and ambitious that very few operating system designs have used it.
The ABIOS must normally be initialized: the initialization process surveys the system configuration, and builds a data structure (the CDA) in System RAM. Process threads (or system software called by process threads) can call on this data structure to get information about the hardware they are running on.
The ABIOS is somewhat analogous to a large-scale machine-specific device driver: a process thread can make calls to the ABIOS by submitting a "request block" into the ABIOS's request-handling queue.
When running on an IBM PS/2 under OS/2, the OS/2+ABIOS combination does make additional DevHlp functions available to device drivers, including provision of a standardized interface which provides some hardware-independence to the device driver software. Thus, the device driver software programs in such a system can include substantially increased functionality. See generally Mizell, "Understanding device drivers in Operating System/2," IBM Systems Journal vol. 27, no. 2 p. 170-84 (1988), which is hereby incorporated by reference.
Within the IBM PS/2 family, the interface to ABIOS is identical, regardless of which IBM PS/2 machine it is running on. Within the IBM PS/2 family, the ABIOS provides a significant degree of machine-independence. Thus the ABIOS has some, but not all, of the same goals as the presently preferred embodiment disclosed herein.
Note that the self-describing system software ex-tension of the presently preferred embodiment provides a lower-level component of system software than the ABIOS referenced above. The ABIOS is itself a full standalone BIOS, and may be thought of as a fancy device driver. By contrast, the conventional BIOS is interrupt-driven. By contrast, the self-describing system software extension will not work as a standalone BIOS, and does not even work as a device driver: instead, the self-describing system software extension merely provides services to device drivers and to standalone application programs.
The self-describing system software extension provides functions which are not addressed by the ABIOS, and conversely the ABIOS addresses a great deal of functionality which is not addressed by self-describing system software extension. Thus, these two software systems are complementary. In fact, it would readily be possible to prepare a modification of self-describing system software extension for use as an ABIOS extension. The ABIOS also includes "hooks" for extending ABIOS; insofar as known to the present inventors, nobody has ever taken the trouble to implement this in a practical system, but there is no apparent reason why this could not be done if desired.
The disclosed self-describing system software extension also provides particular advantages in system diagnostics, which are not provided by ABIOS.
The "XBIOS" of the Atari ST
In internal documentation, the self-describing system software extension of the presently preferred embodiment has frequently been referred to as the "XBIOS," and reflections of that terminology can be seen in the source code appended to the present application. However, to prevent confusion, it must be noted that the term "XBIOS" has also been used for a component of the operating system software in the Atari ST computer. While this software is believed not to have included any of the innovative concepts claimed herein, the similarity, in terminology should be noted. See generally, e.g. Rothman, "Atari ST software development, BYTE magazine, vol. 11 no. 9 (September 1986) at 223ff, which is hereby incorporated by reference. The Atari ST is a 68000-based machine. The ST's operating system (called "TOS") has two main parts: The "GEM" (Graphics Environment Manager) is a complete operating system developed by Digital Research, and is meant to support applications that are portable to other machines. Atari's "XBIOS" (extended BIOS) is meant to support ST-specific capabilities not accessible through GEM.
Additional Background Literature
U.S. Pat. No. 4,589,063, which is hereby incorporated by reference, purports to disclose a "method and apparatus for automatic configuration of a computer system . . . wherein one or more system peripheral or I/O devices can be interfaced to the computer system through I/O boards that plug into a system motherboard. Each of the I/O devices includes a controlling device driver module that operates under a program code stored in a read only memory resident on the I/O board and by which the device driver module allows the computer system to communicate with its associated peripheral and I/O devices. Accordingly, a system user is not required to change the computer operating system kernel to support each new I/O device or system configuration change."